What's broken

Every primary call-to-action link added by this PR points to a bare /academy/<section> URL, but those URLs do not resolve. The affected links are:

content/academy/index.mdx:

• Line 30: [The AI Engineering Loop](/academy/ai-engineering-loop)
• Lines 32–36: /academy/tracing, /academy/monitoring, /academy/datasets, /academy/experiments, /academy/evaluate

content/academy/ai-engineering-loop/overview.mdx:

• Line 18: [Tracing](/academy/tracing)
• Line 22: [Monitoring](/academy/monitoring)
• Line 26: [Datasets](/academy/datasets)
• Line 30: [Experiments](/academy/experiments)
• Line 34: [Evaluate](/academy/evaluate)

Why they 404

I verified directly that each academy subfolder (ai-engineering-loop, tracing, monitoring, datasets, experiments, evaluate) contains only meta.json + overview.mdx — no index.mdx. Under fumadocs-core's default source loader, a file at content/academy/tracing/overview.mdx is exposed at URL /academy/tracing/overview. There is no automatic 'use overview as folder index' fallback — only an index.mdx in a folder takes the bare folder URL. So academySource.getPage(["tracing"]) returns undefined, and app/academy/[[...slug]]/page.tsx:14 falls through to notFound(), rendering AcademyNotFound.

The repo's own precedent confirms this

lib/redirects.js:60-71 explicitly maps these docs paths to their /overview children:

...[
  "/docs/integrations",
  "/docs/scores",
  "/docs/datasets",
  "/docs/security",
  "/docs/observability",
  "/docs/evaluation",
  "/docs/metrics",
  "/docs/api-and-data-platform",
  "/docs/prompt-management",
].map((path) => [path, path + "/overview"]),

These redirects exist precisely because those docs sections have the same structure (only overview.mdx, no index.mdx) and the bare folder URLs do not resolve on their own. Grepping lib/redirects.js for 'academy' returns only an unrelated /customers/khan-academy entry — no /academy/* redirect was added by this PR.

Step-by-step proof

1. User lands on /academy (works — content/academy/index.mdx exists at the root, mapped to /academy).
2. User clicks the first CTA, [Tracing](/academy/tracing), on line 32 of the new index.mdx or line 18 of ai-engineering-loop/overview.mdx.
3. Next.js routes the request to app/academy/[[...slug]]/page.tsx with slug = ["tracing"].
4. academySource.getPage(["tracing"]) looks for a page whose URL path segments are ["tracing"]. The only file under content/academy/tracing/ is overview.mdx, which fumadocs maps to slug ["tracing", "overview"] — no match.
5. Result is undefined, so if (!page) notFound(); triggers.
6. The user sees the AcademyNotFound 404 page.

The same chain applies to all six bare-folder URLs introduced by this PR. The PR landing page itself loads, but the moment a reader clicks any 'next step' link, the journey breaks.

Impact

Every primary CTA in the two pages this PR adds/rewrites is broken. This is a release blocker for the Academy section: the rewritten welcome page exists specifically to send readers to the loop sub-sections, and the new ai-engineering-loop/overview.mdx is structured around five 'Read [section]' links that all 404. Greptile flagged a similar broken link to /academy/error-analysis in the pre-existing monitoring page but missed this systemic issue across the new content.

Fix

Two equivalent options:

1. Append /overview at each link site — change /academy/tracing → /academy/tracing/overview, etc., in both files (matches what lib/nav-links.tsx already does for the docs section).
2. Add redirects to lib/redirects.js analogous to lines 60–71:

...[
  "/academy/ai-engineering-loop",
  "/academy/tracing",
  "/academy/monitoring",
  "/academy/datasets",
  "/academy/experiments",
  "/academy/evaluate",
].map((path) => [path, path + "/overview"]),

Option 2 is more robust because it also catches any future external links that target the bare folder URL.

What the bug is

The new AI Engineering Loop page introduces five cards linking to the loop sub-sections. Four of those cards have single-word titles (Tracing, Monitoring, Experimenting, Evaluating) where casing is unambiguous. The one multi-word card — the third one, for datasets — uses sentence case on the card but Title Case everywhere else in the same PR.

The specific code path

• content/academy/ai-engineering-loop.mdx:47 → title="3. Building datasets" (lowercase d).
• content/academy/datasets/meta.json → "title": "Building Datasets" (uppercase D). This drives the sidebar entry and the page heading.
• content/academy/index.mdx:22 → [Building Datasets](/academy/datasets) (uppercase D). This is the link in the welcome page bullet list.

So the card on the loop page is the only place that uses lowercase d, and it diverges from both the sidebar label of the page it links to and the sibling link in the welcome page list.

Why existing code does not prevent it

There is no shared constant or central source of truth for these section titles — each is hand-typed. Nothing in the build will warn when a card label diverges from its target page title. The other four cards happen to be safe because their titles are single words.

Step-by-step proof

1. Reader opens /academy/ai-engineering-loop and sees five cards. The third reads "3. Building datasets".
2. Reader clicks the card, which navigates to /academy/datasets.
3. fumadocs renders the page using content/academy/datasets/meta.json, whose title is "Building Datasets".
4. The destination page header and sidebar entry both display "Building Datasets" — different casing from the card the reader just clicked.
5. Separately, on /academy (the index page), the bullet list at line 22 shows Building Datasets, also disagreeing with the loop card.

Impact

Purely cosmetic — no broken navigation, no functional issue. But it is the only multi-word card and the only one whose label disagrees with its destination, so the inconsistency is asymmetric and stands out.

Fix

Change content/academy/ai-engineering-loop.mdx:47 from title="3. Building datasets" to title="3. Building Datasets" to align with datasets/meta.json and index.mdx.